home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / iso / 10021_22.asc < prev    next >
Text File  |  1992-12-23  |  78KB  |  1,210 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20. Section Two - Abstract Models
  21. 6.   Overview
  22. This  section  presents  abstract  models  of  Message  Handling  which  provide   the
  23. architectural basis  for  the  more  detailed  specifications  that  appear  in  other
  24. Recommendations in the set.
  25. .I.gl:Message  Handling;  is  a   distributed   information   processing   task   that
  26. integrates the following intrinsically related sub-tasks:
  27. a)    .I.gl:Message  Transfer;:  The  non-real-time  carriage   of   information   objects
  28. between parties using computers as intermediaries.
  29. b)    .I.gl:Message   Storage;:   The   automatic   storage   for   later   retrieval   of
  30. information objects conveyed by means of Message Transfer.
  31. This section covers the following topics:
  32. a)   Functional model
  33. b)   Information model
  34. c)   Operational model
  35. d)   Security model
  36. Note    Message  Handling   has   a   variety   of   applications,   one   of   which   is
  37. Interpersonal Messaging, described in Recommendation X.420.
  38. 7.   Functional Model
  39. This  clause  provides  a   functional   model   of   Message   Handling.   The   concrete
  40. realization of the model is the subject of other Recommendations in the set.
  41. The    .I.gl:Message    Handling    Environment;    (.I.ab:MHE;)    comprises    "primary"
  42. functional objects of several  types,  the  Message  Handling  System  (MHS),  users,  and
  43. distribution  lists.  The  MHS  in  turn  can  be  decomposed  into  lesser,   "secondary"
  44. functional objects of several types, the  Message  Transfer  System  (MTS),  user  agents,
  45. message stores,  and  access  units.  The  MTS  in  turn  can  be  decomposed  into  still
  46. lesser, "tertiary" functional objects of a single type, message transfer agents.
  47. The  primary,  secondary,  and  tertiary  functional  object  types  and  selected  access
  48. unit types are individually defined and described below.
  49. As  detailed  below,  functional  objects  are  sometimes  tailored   to   one   or   more
  50. applications of Message  Handling,  e.g.,  Interpersonal  Messaging  (see  Recommendations
  51. X.420  and  T.330).  A  functional  object  that  has  been  tailored  to  an  application
  52. understands the syntax and semantics  of  the  contents  of  messages  exchanged  in  that
  53. application.
  54. As  a  local   matter,   functional   objects   may   have   capabilities   beyond   those
  55. specified in this Recommendation or others in the  set.  In  particular,  a  typical  user
  56. agent  has  message  preparation,  rendition,  and  storage  capabilities  that  are   not
  57. standardized.
  58. 7.1      Primary Functional Objects
  59. The  MHE  comprises  the  Message  Handling  System,  users,   and   distribution   lists.
  60. These primary functional objects interact  with  one  another.  Their  types  are  defined
  61. and described below.
  62. The situation is depicted in Figure 1/X.402.
  63. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | |  07  |  |  08  |  |  09  |  |  10  |  |
  64. 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 |  |  20  |  |  21  |  |  22  |
  65. | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
  66. Figure .F.:1/X.402 The Message Handling Environment
  67. 7.1.1    The Message Handling System
  68. The  principal  purpose  of  Message  Handling  is  to  convey  information  objects  from
  69. one  party  to  another.   The   functional   object   by   means   of   which   this   is
  70. accomplished is called the .I.gl:Message Handling System; (.I.ab:MHS;).
  71. The MHE comprises a single MHS.
  72. 7.1.2    Users
  73. The  principal  purpose  of  the  MHS  is  to  convey  information  objects  between   users.
  74. A functional object  (e.g.,  a  person)  that  engages  in  (rather  than  provides)  Message
  75. Handling is called a .I.gl:user;.
  76. The following kinds of user are distinguished:
  77. a)   .I.gl:direct  user;:  A  user  that  engages  in  Message  Handling  by  direct  use  of
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84. the MHS.
  85. b)   .I.gl:indirect  user;:  A  user  that  engages  in  Message  Handling  by  indirect  use
  86. of the MHS, i.e., through  another  communication  system  (e.g.,  a  postal  system  or  the
  87. telex network) to which the MHS is linked.
  88. The MHE comprises any number of users.
  89. 7.1.3    Distribution Lists
  90. By means  of  the  MHS  a  user  can  convey  information  objects  to  pre-specified  groups
  91. of users as well as to individual users. The functional object that represents a pre-specified group of users and other DLs is called a .I.gl:distribution list; 
  92. (.I.ab:DL;).
  93. A  DL  identifies  zero  or  more  users  and  DLs  called  its  .I.gl:members;.  The  latter
  94. DLs (if any) are  said  to  be  .I.gl:nested;.  Asking  the  MHS  to  convey  an  information
  95. object (e.g., a message) to a DL is tantamount  to  asking  that  it  convey  the  object  to
  96. its members. Note that this is recursive.
  97. The right, or  permission,  to  convey  messages  to  a  particular  DL  may  be  controlled.
  98. This right is called .I.gl:submit permission;. As  a  local  matter  the  use  of  a  DL  can
  99. be further restricted.
  100. The MHE comprises any number of DLs.
  101. Note   A DL  might  be  further  restricted,  e.g.,  to  the  conveyance  of  messages  of  a
  102. prescribed content type.
  103. 7.2      Secondary Functional Objects
  104. The  MHS  comprises  the  Message  Transfer  System,  user  agents,   message   stores,   and
  105. access units. These secondary functional objects  interact  with  one  another.  Their  types
  106. are defined and described below.
  107. The situation is depicted in Figure 2/X.402.
  108. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08  |  |  09  |  |  10  |  |  11  |
  109. | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23  |
  110. | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
  111. Figure .F.:2/X.402 The Message Handling System
  112. 7.2.1    The Message Transfer System
  113. The MHS conveys  information  objects  to  individual  users  and  to  the  members  of  DLs.
  114. The  functional  object  that  actually  does  this  is  called  the  .I.gl:Message  Transfer
  115. System; (.I.ab:MTS;). The  MTS  is  a  store-and-forward  communication  system  and  can  be
  116. considered the backbone of the MHS.
  117. The  MTS   is   general-purpose,   supporting   all   applications   of   Message   Handling.
  118. Additionally, the MTS may be tailored to one  or  more  particular  applications  so  it  can
  119. carry out conversion.
  120. The MHS comprises a single MTS.
  121. 7.2.2    User Agents
  122. The  functional  object  by  means  of  which  a  single  direct  user  engages  in   Message
  123. Handling is called a .I.gl:user agent; (.I.ab:UA;).
  124. A  typical  UA  is  tailored  to   one   or   more   particular   applications   of   Message
  125. Handling.
  126. The MHS comprises any number of UAs.
  127. Note    A  UA  that  serves  a  human  user  typically  interacts  with  him  by   means   of
  128. input/output devices  (e.g.,  a  keyboard,  display,  scanner,  printer,  or  combination  of
  129. these).
  130. 7.2.3    Message Stores
  131. A  typical  user  must  store  the  information   objects   it   receives.   The   functional
  132. object that provides a  (single)  direct  user  with  capabilities  for  Message  Storage  is
  133. called a .I.gl:message store; (.I.ab:MS;). Each  MS  is  associated  with  one  UA,  but  not
  134. every UA has an associated MS.
  135. Every  MS  is   general-purpose,   supporting   all   applications   of   Message   Handling.
  136. Additionally, an MS may be tailored to one or more particular applications  so  that  it  can
  137. more  capably  submit  and  support  the  retrieval  of   messages   associated   with   that
  138. application.
  139. The MHS comprises any number of MSs.
  140. Note    As  a  local  matter  a  UA  may  provide  for  information  objects   storage   that
  141. either supplements or replaces that of an MS.
  142. 7.2.4    Access Units
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154. The  functional  object  that  links   another   communication   system   (e.g.,   a   postal
  155. system or the telex network) to  the  MTS  and  via  which  its  patrons  engage  in  Message
  156. Handling as indirect users is called an .I.gl:access unit; (.I.ab:AU;).
  157. A typical  AU  is  tailored  to  a  particular  communication  system  and  to  one  or  more
  158. particular applications of Message Handling.
  159. The MHS comprises any number of AUs.
  160. 7.3      Tertiary Functional Objects
  161. The  MTS   comprises   message   transfer   agents.   These   tertiary   functional   objects
  162. interact. Their type is defined and described below.
  163. The situation is depicted in Figure 3/X.402.
  164. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08  |  |  09  |  |  10  |  |  11  |
  165. | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23  |
  166. | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
  167. Figure .F.:3/X.402 The Message Transfer System
  168. 7.3.1    Message Transfer Agents
  169. The MTS conveys  information  objects  to  users  and  DLs  in  a  store-and-forward  manner.
  170. A  functional  object  that  provides  one  link  in  the  MTS'  store-and-forward  chain  is
  171. called a .I.gl:message transfer agent; (.I.ab:MTA;).
  172. Every  MTA  is  general-purpose,   supporting   all   applications   of   Message   Handling.
  173. Additionally, an MTA may be tailored to  one  or  more  particular  applications  so  it  can
  174. carry out conversion.
  175. The MTS comprises any number of MTAs.
  176. 7.4      Selected AU Types
  177. As  described  above,  the  MHS  interworks  with  communication  systems  of   other   types
  178. via  AUs.  Several  selected  AU  types--physical   delivery,   telematic,   and   telex--are
  179. introduced in the clauses below.
  180. 7.4.1    Physical Delivery
  181. A  .I.gl:physical  delivery   access   unit;   (.I.ab:PDAU;)   is   an   AU   that   subjects
  182. messages (but neither probes  nor  reports)  to  physical  rendition  and  that  conveys  the
  183. resulting physical messages to a physical delivery system.
  184. The  transformation  of  a  message  into  a  physical  message  is   called   .I.gl:physical
  185. rendition;. A  .I.gl:physical  message;  is  a  physical  object  (e.g.,  a  letter  and  its
  186. paper envelope) that embodies a message.
  187. A  .I.gl:physical  delivery  system;  (.I.ab:PDS;)  is  a  system  that   performs   physical
  188. delivery.  One  important  kind  of  PDS  is  postal  systems.  .I.gl:Physical  delivery;  is
  189. the conveyance of a physical message to a  patron  of  a  PDS,  one  of  the  indirect  users
  190. to which the PDAU provides Message Handling capabilities.
  191. Among the  applications  of  Message  Handling  supported  by  every  PDAU  is  Interpersonal
  192. Messaging (see Recommendation X.420).
  193. 7.4.2    Telematic
  194. Telematic  access   units,   which   support   Interpersonal   Messaging   exclusively,   are
  195. introduced in Recommendation X.420.
  196. 7.4.3    Telex
  197. Telex   access   units,   which   support   Interpersonal    Messaging    exclusively,    are
  198. introduced in Recommendation X.420.
  199. 8.   Information Model
  200. This  clause  provides   an   information   model   of   Message   Handling.   The   concrete
  201. realization of the model is the subject of other Recommendations in the set.
  202. The MHS  and  MTS  can  convey  information  objects  of  three  classes:  messages,  probes,
  203. and reports. These classes are listed  in  the  first  column  of  Table  4/X.402.  For  each
  204. listed  class,  the  second  column  indicates  the  kinds  of   functional   objects--users,
  205. UAs,  MSs,  MTAs,  and  AUs--that  are  the  ultimate  sources  and  destinations  for   such
  206. objects.
  207. Table .T.:4/X.402 Conveyable Information Objects
  208. +---------+-------------------+ |  Infor-   |  Functional  Object  |  |  mation    +---------
  209. -----------+  |  Object   |  user  UA  MS  MTA   AU   |   +---------+-------------------+   |
  210. message | SD   -  -  -   -  | | probe   | S    -  -  D   -  |  |  report   |  D     -   -   S
  211. -   |  +---------+-------------------+   +-  Legend  ---------------+  |  S  ultimate  source
  212.     | | D ultimate destination | +------------------------+
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219. The  information  objects,  summarized  in  the   table,   are   individually   defined   and
  220. described in the clauses below.
  221. 8.1      Messages
  222. The  primary  purpose  of  Message  Transfer  is  to  convey   information   objects   called
  223. .I.gl:message;s from one user to others. A message  has  the  following  parts,  as  depicted
  224. in Figure 4/X.402:
  225. a)    .I.gl:envelope;:  An   information   object   whose   composition   varies   from   one
  226. transmittal step to another and  that  variously  identifies  the  message's  originator  and
  227. potential  recipients,  documents  its  previous  conveyance  and  directs   its   subsequent
  228. conveyance by the MTS, and characterizes its content.
  229. b)    .I.gl:content;:  An  information   object   that   the   MTS   neither   examines   nor
  230. modifies, except for conversion, during its conveyance of the message.
  231. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08  |  |  09  |  |  10  |  |  11  |
  232. | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23  |
  233. | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
  234. Figure .F.:4/X.402 A Message's Envelope and Content
  235. One piece of  information  borne  by  the  envelope  identifies  the  type  of  the  content.
  236. The  .I.gl:content  type;  is  an  identifier  (an  ASN.1  Object  Identifier   or   Integer)
  237. that denotes the syntax and  semantics  of  the  content  overall.  This  identifier  enables
  238. the  MTS  to  determine  the  message's  deliverability  to  particular  users,  and  enables
  239. UAs and MSs to interpret and process the content.
  240. Another piece  of  information  borne  by  the  envelope  identifies  the  types  of  encoded
  241. information   represented   in   the   content.   An    .I.gl:encoded    information    type;
  242. (.I.ab:EIT;) is an identifier (an ASN.1 Object Identifier or Integer) that denotes the medium
  243. and  format  (e.g.,  IA5  text  or  Group  3  facsimile)  of  individual  portions   of   the
  244. content.  It  further  enables  the  MTS  to  determine  the  message's   deliverability   to
  245. particular users, and to identify opportunities for it to make  the  message  deliverable  by
  246. converting a portion of the content from one EIT to another.
  247. 8.2      Probes
  248. A  second  purpose  of  Message  Transfer   is   to   convey   information   objects   called
  249. .I.gl:probe;s from one user up to but just short of other users (i.e., to  the  MTAs  serving
  250. those  users).  A  probe  describes  a  class  of  message  and  is  used  to  determine  the
  251. deliverability of such messages.
  252. A message described by a probe is called a .I.gl:described message;.
  253. A  probe  comprises   an   envelope   alone.   This   envelope   contains   much   the   same
  254. information as that for a message. Besides bearing the content type and  encoded  information
  255. types of a described message, the probe's envelope bears the length of its content.
  256. The submission of  a  probe  elicits  from  the  MTS  largely  the  same  behavior  as  would
  257. submission  of  any  described  message,  except  that  DL   expansion   and   delivery   are
  258. forgone in the case of the probe. In particular, and  apart  from  the  consequences  of  the
  259. suppression  of  DL  expansion,  the  probe  provokes  the  same   reports   as   would   any
  260. described message. This fact gives probes their utility.
  261. 8.3      Reports
  262. A  third  purpose  of  Message   Transfer   is   to   convey   information   objects   called
  263. reports to users. Generated by the MTS, a  report  relates  the  outcome  or  progress  of  a
  264. message's or probe's transmittal to one or more potential recipient.
  265. The message  or  probe  that  is  the  subject  of  a  report  is  called  its  .I.gl:subject
  266. message; or .I.gl:subject probe;.
  267. A  report  concerning  a  particular  potential  recipient  is  conveyed  to  the  originator
  268. of  the  subject  message  or  probe   unless   the   potential   recipient   is   a   member
  269. recipient. In the latter case, the report is conveyed to the DL of which the member recipient
  270. is a member. As a local  matter  (i.e.,  by  policy  established  for  that  particular  DL),
  271. the report may be  further  conveyed  to  the  DL's  owner;  either  to  another,  containing
  272. DL (in the  case  of  nesting)  or  to  the  originator  of  the  subject  message  or  probe
  273. (otherwise); or both.
  274. The outcome that a single report may relate are of the following kinds:
  275. a)   .I.gl:delivery  report;:  delivery,  export,  or  affirmation  of  the  subject  message
  276. or probe, or DL expansion.
  277. b)    .I.gl:non-delivery  report;:   non-delivery   or   non-affirmation   of   the   subject
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289. message or probe.
  290. A report may comprise one or more delivery and/or non-delivery reports.
  291. A  message  or   probe   may   provoke   several   delivery   and/or   non-delivery   reports
  292. concerning  a  particular  potential  recipient.  Each  marks  the  passage  of  a  different
  293. transmittal step or event.
  294. 9.   Operational Model
  295. This  clause  provides   an   operational   model   of   Message   Handling.   The   concrete
  296. realization of the model is the subject of other Recommendations in the set.
  297. The MHS can convey an  information  object  to  individual  users,  DLs,  or  a  mix  of  the
  298. two.  Such  conveyance  is  accomplished  by  a   process   called   transmittal   comprising
  299. steps and events. The process, its parts, and the  roles  that  users  and  DLs  play  in  it
  300. are defined and described below.
  301. 9.1      Transmittal
  302. The   conveyance   or   attempted   conveyance   of   a   message   or   probe   is    called
  303. .I.gl:transmittal;. Transmittal encompasses a message's conveyance from its originator to its
  304. potential recipients,  and  a  probe's  conveyance  from  its  originator  to  MTAs  able  to
  305. affirm  the  described  messages'  deliverability  to  the  probe's   potential   recipients.
  306. Transmittal also encompasses the conveyance or attempted  conveyance  to  the  originator  of
  307. any reports the message or probe may provoke.
  308. A   transmittal   comprises   a   sequence   of   transmittal    steps    and    events.    A
  309. .I.gl:transmittal step; (or .I.gl:step;) is the conveyance of a message, probe, or report from 
  310. one  functional  object  to  another  "adjacent"  to  it.  A  .I.gl:transmittal  event;   (or
  311. .I.gl:event;) is processing of a  message,  probe,  or  report  within  a  functional  object
  312. that may influence the  functional  object's  selection  of  the  next  transmittal  step  or
  313. event.
  314. The information flow  of  transmittal  is  depicted  in  Figure  5/X.402.  The  figure  shows
  315. the  kinds  of  functional  objects--direct  users,  indirect  users,  UAs,  MSs,  MTAs,  and
  316. AUs--that  may  be  involved   in   a   transmittal,   the   information   objects--messages,
  317. probes, and reports--that may be conveyed between them, and  the  names  of  the  transmittal
  318. steps by means of which those conveyances are accomplished.
  319. The  figure  highlights  the  facts   that   a   message   or   report   may   be   retrieved
  320. repeatedly and that only the  first  conveyance  of  a  retrieved  object  from  UA  to  user
  321. constitutes receipt.
  322. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08  |  |  09  |  |  10  |  |  11  |
  323. | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23  |
  324. | 24 | | 25 | | 26 | | 27 | |  8  |  |  29  |  +----+   +-  Legend  -------------------------
  325. ----------+  |  M  message   ORG  origination    EXP   export      |   |   P   probe      SBM
  326. submission   DLV delivery  | | R report   IMP import       RTR retrieval |  |             TRN
  327. transfer     REC receipt   | +-------------------------------------------+
  328. Figure .F.:5/X.402 The Information Flow of Transmittal
  329. One event  plays  a  distinguished  role  in  transmittal.  Splitting  replicates  a  message
  330. or probe and  divides  responsibility  for  its  immediate  recipients  among  the  resulting
  331. information  objects.  The  potential  recipients  associated  with  a  particular   instance
  332. of a  message  or  probe  are  called  the  .I.gl:immediate  recipient;s.  An  MTA  stages  a
  333. splitting if the next step or event  required  in  the  conveyance  of  a  message  or  probe
  334. to some immediate recipients  differs  from  that  required  in  its  conveyance  to  others.
  335. Each of the step and  event  descriptions  which  follow  assumes  that  the  step  or  event
  336. is  appropriate  for  all  immediate  recipients,  a  situation  that  can  be  created,   if
  337. necessary, by splitting.
  338. 9.2      Transmittal Roles
  339. Users and DLs play  a  variety  of  roles  in  a  message's  or  probe's  transmittal.  These
  340. roles are  informally  categorized  as  "source"  roles,  "destination"  roles,  or  statuses
  341. to which users or DLs can be elevated.
  342. A  user  may  play  the  following  "source"  role  in  the  transmittal  of  a  message   or
  343. probe:
  344. a)    .I.gl:originator;:  The  user  (but  not  DL)  that  is  the  ultimate  source   of   a
  345. message or probe.
  346. A user or  DL  may  play  any  of  the  following  "destination"  roles  in  the  transmittal
  347. of a message or probe:
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354. a)   .I.gl:intended recipient;: One  of  the  users  and  DLs  the  originator  specifies  as
  355. a message's or probe's intended destinations.
  356. b)    .I.gl:originator-specified  alternate  recipient;:  The  user  or  DL   (if   any)   to
  357. which the originator  requests  that  a  message  or  probe  be  conveyed  if  it  cannot  be
  358. conveyed to a particular intended recipient.
  359. c)   .I.gl:member recipient;: A user  or  DL  to  which  a  message  (but  not  a  probe)  is
  360. conveyed as a result of DL expansion.
  361. d)   .I.gl:recipient-assigned alternate  recipient;:  The  user  or  DL  (if  any)  to  which
  362. an intended,  originator-specified  alternate,  or  member  recipient  may  have  elected  to
  363. redirect messages.
  364. A user or DL may attain  any  of  the  following  statuses  in  the  course  of  a  message's
  365. or probe's transmittal:
  366. a)   .I.gl:potential recipient;: Any user  or  DL  to  (i.e.,  toward)  which  a  message  or
  367. probe  is  conveyed  at  any  point  during  the  course  of  transmittal.   Necessarily   an
  368. intended,   originator-specified   alternate,   member,   or   recipient-assigned   alternate
  369. recipient.
  370. b)    .I.gl:actual  recipient;  (or  .I.gl:recipient;):  A  potential  recipient  for   which
  371. delivery or affirmation takes place.
  372. 9.3      Transmittal Steps
  373. The kinds of steps  that  may  occur  in  a  transmittal  are  listed  in  the  first  column
  374. of  Table  5/X.402.  For  each  listed  kind,  the  second  column  indicates  whether   this
  375. Recommendation and others in the set standardize such  steps,  the  third  column  the  kinds
  376. of information objects--messages,  probes,  and  reports--  that  may  be  conveyed  in  such
  377. a  step,  the  fourth  column  the  kinds  of  functional  objects--users,  UAs,  MSs,  MTAs,
  378. and AUs--that may participate in such a step as the object's source or destination.
  379. The table is  divided  into  three  sections.  The  steps  in  the  first  section  apply  to
  380. the  "creation"  of  messages  and  probes,  those  in  the  last  to   the   "disposal"   of
  381. messages and reports, and those  in  the  middle  section  to  the  "relaying"  of  messages,
  382. probes, and reports.
  383. Table .T.:5/X.402 Transmittal Steps
  384. +------------------+--------+-------------+-------------------+                             |
  385. |        |  Information  |     Functional      |  |                   |  Stand-  |    Objects
  386.  |     Objec s        |   |                    |   ard-     +-------------+------------------
  387. --+ | Transmittal Step | ized?  |  M   P   R   |  user  UA  MS  MTA  AU  |  +----------------
  388. ---+--------+-------------+-------------------+  |  origination       |  No      |    x     x
  389.  -  | S    D  -  -   -  | | submission        |  Yes     |   x    x    -   |  -     S   SD  D
  390. -      |     +------------------+--------+-------------+-------------------+     |     import
  391.    | No     |  x   x   x   |  -     -   -   D    S   |  |  transfer          |  Yes     |   x
  392. x   x  | -    -  -  SD  -  | |  export            |  No      |   x    x    x   |  -     -   -
  393. S     D    |   +------------------+--------+-------------+-------------------+   |   delivery
  394.       | Yes    |  x   -   x  | -    D   D   S    -   |  |  retrieval         |  Yes     |   x
  395.  -   x  | -    D  S  -   -  | | receipt           |  No      |   x    -    x   |  D     S   -
  396. -     -    |   +------------------+--------+-------------+-------------------+    +-   Legend
  397. ------------------------------+ |  M  message   S  source        x  permitted  |  |  P  probe
  398.  D destinati n               |  |  R   report                                |   +-----------
  399. -----------------------------+
  400. The  kinds  of  transmittal  steps,  summarized  in  the  table,  are  individually   defined
  401. and described in the clauses below.
  402. 9.3.1    Origination
  403. In an  .I.gl:origination;  step,  either  a  direct  user  conveys  a  message  or  probe  to
  404. its UA, or an  indirect  user  conveys  a  message  or  probe  to  the  communication  system
  405. that serves it. This step gives birth to the message or  probe  and  is  the  first  step  in
  406. its transmittal.
  407. The  user  above  constitutes  the  message's  or  probe's  originator.  In  this  step,  the
  408. originator identifies  the  message's  or  probe's  intended  recipients.  Additionally,  for
  409. each intended recipient, the originator may (but need not) identify an originator-specified alternate recipient.
  410. 9.3.2    Submission
  411. In  a  .I.gl:submission;  step,  a  message  or  probe  is  conveyed  to  an  MTA  and   thus
  412. entrusted to the MTS. Two kinds of submission are distinguished:
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424. a)    .I.gl:indirect  submission;:  A  transmittal  step  in  which   the   originator's   UA
  425. conveys a message or probe to  its  MS  and  in  which  the  MS  effects  direct  submission.
  426. Such a step follows origination.
  427.      This step may be taken only if the user is equipped with an MS.
  428. b)   .I.gl:direct submission;: A  transmittal  step  in  which  the  originator's  UA  or  MS
  429. conveys a message or probe  to  an  MTA.  Such  a  step  follows  origination  or  occurs  as
  430. part of indirect submission.
  431.      This step may be taken whether or not the user is equipped with an MS.
  432. Indirect  and  direct  submission  are  functionally  equivalent   except   that   additional
  433. capabilities  may  be  available  with  the  former.  Indirect  submission  may  differ  from
  434. direct submission in other respects (e.g.,  the  number  of  open  systems  with  which  that
  435. embodying  a  UA  must  interact)   and   for   that   reason   be   preferable   to   direct
  436. submission.
  437. The UA or MS  involved  in  direct  submission  is  called  the  .I.gl:submission  agent;.  A
  438. submission agent is made known to  the  MTS  by  a  process  of  registration,  as  a  result
  439. of  which  the  submission  agent  and  MTS  keep  one  another  informed  of  their   names,
  440. their locations, and any other characteristics required for their interaction.
  441. 9.3.3    Import
  442. In an .I.gl:import; step, an AU  conveys  a  message,  probe,  or  report  to  an  MTA.  This
  443. step  injects  into  the  MTS  an  information   object   born   in   another   communication
  444. system, and follows its conveyance by that system.
  445. Note   The concept of importing  is  a  generic  one.  How  this  step  is  effected  varies,
  446. of course, from one type of AU to another.
  447. 9.3.4    Transfer
  448. In a .I.gl:transfer;  step,  one  MTA  conveys  a  message,  probe,  or  report  to  another.
  449. This   step   transports   an   information    object    over    physical    and    sometimes
  450. organizational distances and follows direct submission, import, or (a prior) transfer.
  451. This step may be taken, of course, only if the MTS comprises several MTAs.
  452. The  following  kinds  of  transfer  are  distinguished,  on  the  basis  of  the  number  of
  453. MDs involved:
  454. a)   .I.gl:internal transfer;: A transfer involving MTAs within a single MD.
  455. b)   .I.gl:external transfer;: A transfer involving MTAs in different MDs.
  456. 9.3.5    Export
  457. In an .I.gl:export; step, an MTA  conveys  a  message,  probe,  or  report  to  an  AU.  This
  458. step  ejects  from  the  MTS  an  information  object   bound   for   another   communication
  459. system. It follows direct submission, import, or transfer.
  460. As part of this step, the MTA may generate a delivery report.
  461. Note   The concept of exporting  is  a  generic  one.  How  this  step  is  effected  varies,
  462. of course, from one type of AU to another.
  463. 9.3.6    Delivery
  464. In a .I.gl:delivery; step, an  MTA  conveys  a  message  or  report  to  an  MS  or  UA.  The
  465. MS and UA are those of a potential recipient  of  the  message,  or  the  originator  of  the
  466. report's  subject  message  or  probe.  This  step  entrusts  the  information  object  to  a
  467. representative of the user and follows  direct  submission,  import,  or  transfer.  It  also
  468. elevates the user in question to the status of an actual recipient.
  469. As part of  this  step,  in  the  case  of  a  message,  the  MTA  may  generate  a  delivery
  470. report.
  471. The MS or UA involved  is  called  the  .I.gl:delivery  agent;.  A  delivery  agent  is  made
  472. known to the  MTS  by  a  process  of  registration,  as  a  result  of  which  the  delivery
  473. agent and MTS keep one another informed of  their  names,  their  locations,  and  any  other
  474. characteristics required for their interaction.
  475. 9.3.7    Retrieval
  476. In a .I.gl:retrieval; step, a  user's  MS  conveys  a  message  or  report  to  its  UA.  The
  477. user  in  question  is  an  actual  recipient  of  the  message  or  the  originator  of  the
  478. subject message or probe.  This  step  non-destructively  retrieves  the  information  object
  479. from storage. This step follows delivery or (a prior) retrieval.
  480. This step may be taken only if the user is equipped with an MS.
  481. 9.3.8    Receipt
  482. In  a  .I.gl:receipt;  step,  either  a  UA  conveys  a  message  or  report  to  its  direct
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489. user,  or  the  communication  system  that  serves  an  indirect  user   conveys   such   an
  490. information object to that user. In  either  case,  this  step  conveys  the  object  to  its
  491. ultimate destination.
  492. In  the  case  of  a  direct  user,  this  step  follows  the  object's  delivery  or   first
  493. retrieval (only). In the case of an  indirect  user,  it  follows  the  information  object's
  494. conveyance by the communication system  serving  the  user.  In  either  case,  the  user  is
  495. a potential recipient  (and,  in  the  case  of  a  direct  user,  an  actual  recipient)  of
  496. the message in question, or the originator of the subject message or probe.
  497. 9.4      Transmittal Events
  498. The kinds of events that  may  occur  in  a  transmittal  are  listed  in  the  first  column
  499. of  Table  6/X.402.  For  each  listed  kind,  the  second  column  indicates  the  kinds  of
  500. information  objects--messages,  probes,  and  reports--for  which   such   events   may   be
  501. staged, the third column the kinds of functional objects--users, UAs, MS ,  MTAs,  and  AUs--
  502. -that may stage such events.
  503. All the events occur within the MTS.
  504. Table .T.:6/X.402 Transmittal Events
  505. +-------------------+-------------+-------------------+         |                           |
  506. Information |    Functional     | |                   |    Objects    |      Objects        |
  507. |                    +-------------+-------------------+  |  Transmittal  Event  |    M     P
  508.  R   |  user  UA  MS  MTA  AU  |  +-------------------+-------------+-------------------+   |
  509. splitting         |  x   x   -  |  -     -   -   x    -   |  |  joining            |   x    x
  510. x  | -    -  -  x   -  | | name resolution   |   x    x    -   |  -     -   -   x    -   |  |
  511. DL expansion      |  x   -   -  |  -     -   -   x    -   |  |  redirection        |   x    x
  512. -  | -    -  -  x   -  | | conversion        |   x    x    -   |  -     -   -   x    -   |  |
  513. non-delivery      |  x   -   x  |  -     -   -   x    -   |  |  non-affirmation    |   -    x
  514. -  | -    -  -  x   -  | | affirmation       |   -    x    -   |  -     -   -   x    -   |  |
  515. routing           |  x   x   x  |  -     -   -   x    -   |  +-------------------+-----------
  516. ---+-------------------+  +-  Legend  ---------------+  |  M  message   x  permitted  |  |  P
  517. probe                | | R report               | +------------------------+
  518. The  kinds  of  transmittal  events,  summarized  in  the  table,  are  individually  defined
  519. and described in the clauses below.
  520. 9.4.1    Splitting
  521. In  a  .I.gl:splitting;  event,  an   MTA   replicates   a   message   or   probe,   dividing
  522. responsibility for its immediate recipients among the  resulting  information  objects.  This
  523. event  effectively  allows  an  MTA  to   independently   convey   an   object   to   various
  524. potential recipients.
  525. An MTA stages a splitting when  the  next  step  or  event  required  in  the  conveyance  of
  526. a message  or  probe  to  some  immediate  recipients  differs  from  that  required  in  its
  527. conveyance to others.
  528. 9.4.2    Joining
  529. In a .I.gl:joining; event,  an  MTA  combines  several  instances  of  the  same  message  or
  530. probe,  or  two  or  more  delivery  and\or  non-delivery  reports  for  the   same   subject
  531. message or probe.
  532. An MTA may,  but  need  not  stage  a  joining  when  it  determines  that  the  same  events
  533. and next  step  are  required  to  convey  several  highly  related  information  objects  to
  534. their destinations.
  535. 9.4.3    Name Resolution
  536. In a .I.gl:name resolution;  event,  an  MTA  adds  the  corresponding  O/R  address  to  the
  537. O/R name that identifies one of a message's or probe's immediate recipients.
  538. 9.4.4    DL Expansion
  539. In a .I.gl:DL expansion;  event,  an  MTA  resolves  a  DL  among  a  message's  (but  not  a
  540. probe's)  immediate   recipients   to   its   members   which   are   thereby   made   member
  541. recipients. This event removes indirection from the immediate recipients' specification.
  542. A  particular  DL  is  always  subjected  to  DL  expansion  at  a  pre-established  location
  543. within  the  MTS.  This  location  is  called  the  DL's  .I.gl:expansion   point;   and   is
  544. identified by an O/R address.
  545. As part of this event, the MTA may generate a delivery report.
  546. DL  expansion  is  subject  to  submit  permission.  In  the  case  of  a  nested  DL,   that
  547. permission must  have  been  granted  to  the  DL  of  which  the  nested  DL  is  a  member.
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559. Otherwise, it must have been granted to the originator.
  560. 9.4.5    Redirection
  561. In a  .I.gl:redirection;  event,  an  MTA  replaces  a  user  or  DL  among  a  message's  or
  562. probe's   immediate   recipients   with   an   originator-specified   or   recipient-assigned
  563. alternate recipient.
  564. 9.4.6    Conversion
  565. In  a  .I.gl:conversion;  event,  an  MTA  transforms  parts  of  a  message's  content  from
  566. one EIT to another, or alters a  probe  so  it  appears  that  the  described  messages  were
  567. so modified.  This  event  increases  the  likelihood  that  an  information  object  can  be
  568. delivered or affirmed by tailoring it to its immediate recipients.
  569. The following kinds of conversion  are  distinguished,  on  the  basis  of  how  the  EIT  of
  570. the  information  to  be  converted  and  the  EIT  to  result  from   the   conversion   are
  571. selected:
  572. a)    .I.gl:explicit  conversion;:  A  conversion  in  which  the  originator  selects   both
  573. the initial and final EITs.
  574. b)    .I.gl:implicit  conversion;:  A  conversion  in  which  the  MTA  selects   the   final
  575. EITs based upon the initial EITs.
  576. 9.4.7    Non-delivery
  577. In  a  .I.gl:non-delivery;  event,  an  MTA  determines  that  the  MTS  cannot   deliver   a
  578. message to its immediate recipients,  or  cannot  deliver  a  report  to  the  originator  of
  579. its subject message or  probe.  This  event  halts  the  conveyance  of  an  object  the  MTS
  580. deems unconveyable.
  581. As part of this  event,  in  the  case  of  a  message,  the  MTA  generates  a  non-delivery
  582. report.
  583. An  MTA  stages   a   non-delivery,   e.g.,   when   it   determines   that   the   immediate
  584. recipients are improperly specified, that they do not accept delivery of messages  like  that
  585. at hand, or that the message has  not  been  delivered  to  them  within  pre-specified  time
  586. limits.
  587. 9.4.8    Non-affirmation
  588. In a .I.gl:non-affirmation;  event,  an  MTA  determines  that  the  MTS  could  not  deliver
  589. a described message to  a  probe's  immediate  recipients.  This  event  partially  or  fully
  590. determines the answer to the question posed by a probe.
  591. As part of this event, the MTA generates a non-delivery report.
  592. An  MTA  stages  a  non-affirmation,  e.g.,   when   it   determines   that   the   immediate
  593. recipients are improperly specified or would not accept delivery of a described message.
  594. 9.4.9    Affirmation
  595. In  an  .I.gl:affirmation;  event,  an  MTA  determines  that  the  MTS  could  deliver   any
  596. described  message  to  a  probe's  immediate  recipients.  This  event  partially  or  fully
  597. determines the answer  to  the  question  posed  by  a  probe,  and  elevates  the  immediate
  598. recipients to the status of actual recipients.
  599. As part of this event, the MTA may generate a delivery report.
  600. An  MTA  stages  an  affirmation  once  it  determines  that  the  immediate  recipients  are
  601. properly specified  and,  if  the  immediate  recipients  are  users  (but  not  DLs),  would
  602. accept delivery of any described message. If  the  immediate  recipients  are  DLs,  and  MTA
  603. stages an  affirmation  if  the  DL  exists  and  the  originator  has  the  relevant  submit
  604. permission.
  605.  
  606.  
  607. 9.4.10   Routing
  608. In  a  .I.gl:routing;  event,  an  MTA  selects  the  "adjacent"  MTA  to   which   it   will
  609. transfer a message, probe, or report. This  event  incrementally  determines  an  information
  610. object's  route  through  the  MTS  and  (obviously)  may  be   taken   only   if   the   MTS
  611. comprises several MTAs.
  612. The  following  kinds  of  routing  are  distinguished,  on  the  basis  of   the   kind   of
  613. transfer for which they prepare:
  614. a)   .I.gl:internal routing;:  A  routing  preparatory  to  an  internal  transfer  (i.e.,  a
  615. transfer within an MD).
  616. b)   .I.gl:external routing;:  A  routing  preparatory  to  an  external  transfer  (i.e.,  a
  617. transfer between MDs).
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624. An MTA stages  a  routing  when  it  determines  that  it  can  stage  no  other  event,  and
  625. take no step, regarding an object.
  626. 10.      Security Model
  627. This  clause  provides  an  abstract  security  model  for  Message  Transfer.  The  concrete
  628. realization  of  the  model  is  the  subject  of  other  Recommendations  in  the  set.  The
  629. security model provides a  framework  for  describing  the  security  services  that  counter
  630. potential threats  (see  annex  D)  to  the  MTS  and  the  security  elements  that  support
  631. those services.
  632. The  security  features  are  an  optional  extension  to  the  MHS  that  can  be  used   to
  633. minimise the risk of exposure of assets and resources to  violations  of  a  security  policy
  634. (threats).  Their  aim  is  to  provide  features   independently   of   the   communications
  635. services provided by other lower or higher entities. Threats may  be  countered  by  the  use
  636. of  physical  security,   computer   security   (.I.ab:COMPUSEC;),   or   security   services
  637. provided by the MHS. Depending  on  the  perceived  threats,  certain  of  the  MHS  security
  638. services  will  be  selected  in  combination  with   appropriate   physical   security   and
  639. COMPUSEC measures. The security services supported  by  the  MHS  are  described  below.  The
  640. naming and structuring of the services are based on ISO 7498-2.
  641. Note  -  Despite  these  security  features,  certain  attacks  may  by  be  mounted  against
  642. communication between a  user  and  the  MHS  or  against  user-to-user  communication  (e.g.
  643. in  the  case  of  users  accessing  their  UAs).   To   counter   these   attacks   requires
  644. extensions to the present security model and services which are for further study.
  645.  
  646. In many cases, the  broad  classes  of  threats  are  covered  by  several  of  the  services
  647. listed.
  648. The security  services  are  supported  through  use  of  service  elements  of  the  Message
  649. Transfer  Service  message  envelope.  The  envelope  contains  security  relevant  arguments
  650. as described in  Recommendation  X.411.  The  description  of  the  security  services  takes
  651. the following  general  form.  In  clause  10.2  the  services  are  listed,  with,  in  each
  652. case, a definition of the service  and  an  indication  of  how  it  may  be  provided  using
  653. the security  elements  in  Recommendation  X.411.  In  clause  10.3  the  security  elements
  654. are individually described,  with,  in  each  case,  a  definition  of  the  service  element
  655. and references to its constituent arguments in Recommendation X.411.
  656. Many  of  the   techniques   employed   rely   on   encryption   mechanisms.   The   security
  657. services in the MHS allow for flexibility in the  choice  of  algorithms.  However,  in  some
  658. cases  only  the  use  of  asymmetric   encryption   has   been   fully   defined   in   this
  659. Recommendation. A future version of this Recommendation may make use of alternative mechanisms 
  660. based on symmetric encipherment.
  661. Note    The  use  of  the  terms  "security  service"  and   "security   element"   in   this
  662. clause are not to be confused with the terms "service"  and  "element  of  service"  as  used
  663. in Recommendation X.400. The former  terms  are  used  in  the  present  clause  to  maintain
  664. consistency with ISO 7498-2.
  665. 10.1     Security Policies
  666. Security services in the MHS  must  be  capable  of  supporting  a  wide  range  of  security
  667. policies which  extend  beyond  the  confines  of  the  MHS  itself.  The  services  selected
  668. and  the  threats  addressed  will  depend  on  the  individual  application  and  levels  of
  669. trust in parts of the system.
  670. A security policy defines how  the  risk  to  and  exposure  of  assets  can  be  reduced  to
  671. an acceptable level.
  672. In  addition,  operation  between  different  domains,   each   with   their   own   security
  673. policy, will be required. As each  domain  will  be  subject  to  its  own  overall  security
  674. policy, covering more than just the  MHS,  a  bilateral  agreement  on  interworking  between
  675. two domains will be  required.  This  must  be  defined  so  as  not  to  conflict  with  the
  676. security  policies  for  either  domain  and  effectively  becomes  part   of   the   overall
  677. security policy for each domain.
  678. 10.2     Security Services
  679. This  clause   defines   the   Message   Transfer   security   services.   The   naming   and
  680. structuring of the services are based on ISO 7498-2.
  681. MHS  security  services  fall  into  several   broad   classes.   These   classes   and   the
  682. services in each are listed in Table 7/X.402. An  asterisk  (*)  under  the  heading  of  the
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694. form X/Y indicates that the service can be provided  from  a  functional  object  of  type  X
  695. to one of type Y.
  696. Table .T.:7/X.402 Message Transfer Security Services
  697. +-------------------------------+-------------------------------+                           |
  698.              |  UA/UA  MS/MTA  UA/MTA   MTA/UA      |   |   SERVICE                         |
  699. UA/MS UA/M A  MTA/MTA  MS/UA  |  +-  ORIGIN  AUTHENTICATION   -------+-----------------------
  700. ---------+ | Message Origin Authentication |   *  *   -   *    -    -    -   -    |  |  Probe
  701. Origin  Authentication    |    -   -   *   *    -    -     -    -     |   |   Report   Origin
  702. Authentication  |   -  -  -  -   *   *   -  -   | | Proof of Submission           |   -  -  -
  703. -   -   -   *  -   | | Proof of Delivery              |    *   -   -   -    -    -    -  Note
  704. |  +-  SECURE  ACCESS  MANAGEMENT   ----+-------------------------------+   |   Peer   Entity
  705. Authentication    |   -  *  *  *   *    *    *   *    |  |  Security  Context               |
  706. -  *  *  *    *    *    *   *    |  +-  DATA  CONFIDENTIALITY  --------+---------------------
  707. -----------+ |  Connection  Confidentiality     |    -   *   *   *    *    *    *   *    |  |
  708. Content  Confidentiality        |    *   -   -   -    -    -    -   -    |  |  Message   Flow
  709. Confidentiality  |   *  -  -  -   -   -   -  -   | +- DATA INTEGRITY SERVICES -----+-------- 
  710. -----------------------+ |  Connection  Integrity           |    -   *   *   *    *    *    *
  711. *   | | Content Integrity              |    *   -   -   -    -    -    -   -    |  |  Message
  712. Sequence Integrity    |   *  -  -  -   -   -    -   -    |  +-  NON-REPUDIATION  ------------
  713. --+-------------------------------+  |  Non-repudiation  of  Origin      |    *   -    -    *
  714. -   -   -  -   | | Non-repudiation of Submission |   -   -   -   -    -    -    *   -    |  |
  715. Non-repudiation of Delivery   |   *   -   -   -    -    -    -   -    |  |  Message  Security
  716. Labelling    |   *  *  *  *   *   *   *   *    |  +-  SECURITY  MANAGEMENT  SERVICES  +------
  717. --------------------------+  |  Change  Credentials             |    -   *   -   *    *     *
  718. *  -   | | Register                      |   -  *   -   *    -    -    -   -    |  +---------
  719. -----------------------+-------------------------------+     Note      This    service     is
  720. provided by the recipient's MS to the originator's UA.
  721. Throughout  the  security  service  definitions   that   follow,   reference   is   made   to
  722. Figure 6/X.402, which reiterates the MHS functional model in  simplified  form.  The  numeric
  723. labels are referenced in the text.
  724. +------+                   +------+  |   1    |                   |    5     |   |   MTS-   |
  725.            | MT -  |  |  user  |                   |  user  |  +------+                   +--
  726. -----+  |                          |  +------+      +------+      +------+  |   2    |      |
  727. 3   |     |  4   |  |  MTA   |-----|  MTA   |-----|  MTA   |  |       |      |       |      |
  728.   | +------+     +------+     +------+
  729. Figure .F.:6/X.402 Simplified MHS Functional Model
  730. 10.2.1   Origin Authentication Security Services
  731. These   security   services   provide   for   the   authentication   of   the   identity   of
  732. communicating peer entities and sources of data.
  733. 10.2.1.1      Data Origin Authentication Security Services
  734. These security services  provide  corroboration  of  the  origin  of  a  message,  probe,  or
  735. report to all  concerned  entities  (i.e.,  MTAs  or  recipient  MTS-users).  These  security
  736. services cannot protect against duplication of messages, probes, or reports.
  737. 10.2.1.1.1    Message Origin Authentication Security Service
  738. The  Message  Origin  Authentication  Service  enables  the  corroboration  of   the   source
  739. of a message.
  740. This   security   service   can   be   provided   using    either    the    Message    Origin
  741. Authentication or the Message Argument Integrity security element. The former can be used  to
  742. provide the security  service  to  any  of  the  parties  concerned  (1-5  inclusive  in  the
  743. figure), whereas the latter can only be used to provide the  security  service  to  MTS-users
  744. (1  or  5  in  the  figure).  The  security  element  chosen  depends   on   the   prevailing
  745. security policy.
  746. 10.2.1.1.2    Probe Origin Authentication Security Service
  747. The  Probe  Origin  Authentication  security  service  enables  the  corroboration   of   the
  748. source of a probe.
  749. This  security  service  can  be  provided  by  using   the   Probe   Origin   Authentication
  750. security element. This security element can be  used  to  provide  the  security  service  to
  751. any of the MTAs through which the probe is transferred (2-4 inclusive in the figure).
  752. 10.2.1.1.3    Report Origin Authentication Security Service
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759. The  Report  Origin  Authentication  security  service  enables  the  corroboration  of   the
  760. source of a report.
  761. This  security  service  can  be  provided  by  using  the   Report   Origin   Authentication
  762. security element. This security element can be  used  to  provide  the  security  service  to
  763. the originator of the subject message  or  probe,  as  well  as  to  any  MTA  through  which
  764. the report is transferred (1-5 inclusive in the figure).
  765. 10.2.1.2      Proof of Submission Security Service
  766. This  security  service  enables  the  originator  of  a  message  to  obtain   corroboration
  767. that  it  has  been  received  by  the  MTS  for  delivery  to   the   originally   specified
  768. recipient(s).
  769. This  security  service  can  be  provided  by  using  the  Proof  of   Submission   security
  770. element.
  771. 10.2.1.3      Proof of Delivery Security Service
  772. This  security  service  enables  the  originator  of  a  message  to  obtain   corroboration
  773. that it has been delivered by the MTS to its intended recipient(s).
  774. This  security  service  can  be  provided  by  using  the   Proof   of   Delivery   security
  775. element.
  776. 10.2.2   Secure Access Management Security Service
  777. The   Secure   Access   Management   security   service   is   concerned    with    providing
  778. protection for resources  against  their  unauthorised  use.  It  can  be  divided  into  two
  779. components, namely the Peer Entity Authentication and the Security Context security services.
  780. 10.2.2.1      Peer Entity Authentication Security Service
  781. This security  service  is  provided  for  use  at  the  establishment  of  a  connection  to
  782. confirm the identity of the connecting entity.  It  may  be  used  on  the  links  1-2,  2-3,
  783. 3-4, or 4-5 in the  figure  and  provides  confidence,  at  the  time  of  usage  only,  that
  784. an  entity  is  not  attempting  a  masquerade  or  an  unauthorised  replay  of  a  previous
  785. connection.
  786. This  security  service  is  supported  by  the  Authentication  Exchange  security  element.
  787. Note  that  use  of  this  security  element  may  yield  other  data  as  a  result  of  its
  788. operation  that  in  certain  circumstances   can   be   used   to   support   a   Connection
  789. Confidentiality and/or a Connection Integrity security service.
  790. 10.2.2.2      Security Context Security Service
  791. This  security  service  is  used  to  limit  the  scope  of  passage  of  messages   between
  792. entities by reference  to  the  Security  Labels  associated  with  messages.  This  security
  793. service  is  therefore  closely  related  to  the   Message   Security   Labelling   security
  794. service, which provides for the association of messages and Security Labels.
  795. The Security  Context  security  service  is  supported  by  the  Security  Context  and  the
  796. Register security elements.
  797. 10.2.3   Data Confidentiality Security Services
  798. These  security  services  provide  for  the  protection   of   data   against   unauthorised
  799. disclosure.
  800. 10.2.3.1      Connection Confidentiality Security Service
  801. The  MHS  does  not  provide  a  Connection  Confidentiality   security   service.   However,
  802. data  for  the  invocation  of  such  a  security  service  in  underlying  layers   may   be
  803. provided as a result of using the Authentication Exchange security  element  to  provide  the
  804. Peer Entity Authentication  security  service.  The  security  service  may  be  required  on
  805. any of links 1-2, 2-3, 3-4, or 4-5 in the figure.
  806. 10.2.3.2      Content Confidentiality Security Service
  807. The  Content  Confidentiality  security  service  provides  assurance  that  the  content  of
  808. a message is only known to the sender and recipient of a message.
  809. It  may  be  provided  using  a  combination  of  the   Content   Confidentiality   and   the
  810. Message Argument Confidentiality security  elements.  The  Message  Argument  Confidentiality
  811. security element can be used to transfer  a  secret  key  which  is  used  with  the  Content
  812. Confidentiality  security  element   to   encipher   the   message   content.   Using   these
  813. security elements the service is provided from MTS-user  1  to  MTS-user  5  in  the  figure,
  814. with the message content being unintelligible to MTAs.
  815. 10.2.3.3      Message Flow Confidentiality Security Service
  816. This  security  service  provides  for  the  protection  of  information   which   might   be
  817. derived from observation of message flow. Only  a  limited  form  of  this  security  service
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829. is provided by the MHS.
  830. The Double Enveloping  Technique  enables  a  complete  message  to  become  the  content  of
  831. another  message.  This  could  be  used  to  hide  addressing   information   from   certain
  832. parts of the MTS. Used in conjunction with traffic padding (which  is  beyond  the  scope  of
  833. this  Recommendation)  this  could  be  used  to  provide   message   flow   confidentiality.
  834. Other elements of this service, such as  routing  control  or  pseudonyms,  are  also  beyond
  835. the scope of this Recommendation.
  836. 10.2.4   Data Integrity Security Services
  837. These security services are provided to counter active threats to the MHS.
  838. 10.2.4.1      Connection Integrity Security Service
  839. The MHS does  not  provide  a  Connection  Integrity  security  service.  However,  data  for
  840. the invocation  of  such  a  security  service  in  underlying  layers  may  be  provided  by
  841. using  the  Authentication  Exchange  security   element   to   provide   the   Peer   Entity
  842. Authentication security service. The security service may be required on any of links 1-2, 2-3, 3-4, or 4-5 in the figure.
  843. 10.2.4.2      Content Integrity Security Service
  844. This  security  service  provides  for  the  integrity  of   the   contents   of   a   single
  845. message. This takes the form of enabling the determination of  whether  the  message  content
  846. has  been  modified.  This  security  service  does  not  enable  the  detection  of  message
  847. replay, which is provided by the Message Sequence Integrity security service.
  848. This  security  service  can  be  provided  in  two  different  ways  using   two   different
  849. combinations of security elements.
  850. The  Content  Integrity  security  element  together  with  the  Message  Argument  Integrity
  851. security  element  and,  in  some  cases,  the  Message  Argument  Confidentiality   security
  852. element can be used to provide the  security  service  to  a  message  recipient,  i.e.,  for
  853. communication  from  MTS-user  1  to  MTS-user  5  in  the  figure.  The  Content   Integrity
  854. security element is used  to  compute  a  Content  Integrity  Check  as  a  function  of  the
  855. entire message content. Depending on  the  method  used  to  compute  the  Content  Integrity
  856. Check, a secret key may be  required,  which  may  be  confidentially  sent  to  the  message
  857. recipient  using  the  Message  Argument  Confidentiality  security  element.   The   Content
  858. Integrity  Check  is  protected  against  change  using  the   Message   Argument   Integrity
  859. security element. The integrity of any  confidential  message  arguments  is  provided  using
  860. the Message Argument Confidentiality security element.
  861. The Message Origin  Authentication  security  element  can  also  be  used  to  provide  this
  862. security service.
  863. 10.2.4.3      Message Sequence Integrity Security Service
  864. This  security  service  protects  the  originator   and   recipient   of   a   sequence   of
  865. messages against re-ordering of the sequence. In doing  so  it  protects  against  replay  of
  866. messages.
  867. This  security  service  may  be  provided  using  a  combination  of  the  Message  Sequence
  868. Integrity and the Message  Argument  Integrity  security  elements.  The  former  provides  a
  869. sequence number to each message, which  may  be  protected  against  change  by  use  of  the
  870. latter.  Simultaneous  confidentiality  and  integrity  of  the   Message   Sequence   Number
  871. may be provided by use of the Message Argument Confidentiality security element.
  872. These  security  elements  provide  the  service  for  communication  from  MTS-user   1   to
  873. MTS-user 5 in the figure, and not to the intermediate MTAs.
  874. 10.2.5   Non-Repudiation Security Services
  875. These  security  services  provide  irrevocable  proof   to   a   third   party   after   the
  876. message has been submitted, sent, or delivered, that  the  submission,  sending,  or  receipt
  877. did occur as claimed.  Note  that  for  this  to  function  correctly,  the  security  policy
  878. must explicitly cover the management of asymmetric keys for the purpose of non-repudiation services if asymmetric algorithms are being used.
  879. 10.2.5.1      Non-repudiation of Origin Security Service
  880. This security  service  provides  the  recipient(s)  of  a  message  with  irrevocable  proof
  881. of  the  origin  of  the  message,  its  content,  and  its   associated   Message   Security
  882. Label.
  883. This  security  service  can  be  provided  in  two  different  ways  using   two   different
  884. combinations  of  security  elements.  Note  that  its  provision  is  very  similar  to  the
  885. provision of the (weaker) Content Integrity security service.
  886. The  Content  Integrity  security  element  together  with  the  Message  Argument  Integrity
  887. security  element  and,  in  some  cases,  the  Message  Argument  Confidentiality   security
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894. element  can  be  used  to  provide  the  service  to  a   message   recipient,   i.e.,   for
  895. communication from MTS-user 1 to MTS-user 5 in the figure.  The  Content  Integrity  security
  896. element is  used  to  compute  a  Content  Integrity  Check  as  a  function  of  the  entire
  897. message content. Depending on the method used to  compute  the  Content  Integrity  Check,  a
  898. secret key may be required, which  may  be  confidentially  sent  to  the  message  recipient
  899. using  the  Message  Argument  Confidentiality  security  element.  The   Content   Integrity
  900. Check  and,  if  required,  the  Message  Security  Label  are   protected   against   change
  901. and/or  repudiation  using   the   Message   Argument   Integrity   security   element.   Any
  902. confidential message arguments are protected against  change  and/or  repudiation  using  the
  903. Message Argument Confidentiality security element.
  904. If the  Content  Confidentiality  security  service  is  not  required,  the  Message  Origin
  905. Authentication  security  element  may  also  be  used  as  a   basis   for   this   security
  906. service. In this case the security service may be  provided  to  all  elements  of  the  MHS,
  907. i.e., for all of 1-5 in the figure.
  908. 10.2.5.2      Non-Repudiation of Submission Security Service
  909. This security  service  provides  the  originator  of  the  message  with  irrevocable  proof
  910. that the message  was  submitted  to  the  MTS  for  delivery  to  the  originally  specified
  911. recipient(s).
  912. This security service  is  provided  using  the  Proof  of  Submission  security  element  in
  913. much the same way as that  security  element  is  used  to  support  the  (weaker)  Proof  of
  914. Submission security service.
  915. 10.2.5.3      Non-Repudiation of Delivery Security Service
  916. This security  service  provides  the  originator  of  the  message  with  irrevocable  proof
  917. that the message was delivered to its originally specified recipient(s).
  918. This  security  service  is  provided  using  the  Proof  of  Delivery  security  element  in
  919. much the same way as that  security  element  is  used  to  support  the  (weaker)  Proof  of
  920. Delivery security service.
  921. 10.2.6   Message Security Labelling Security Service
  922. This security  service  allows  Security  Labels  to  be  associated  with  all  entities  in
  923. the MHS, i.e., MTAs  and  MTS-users.  In  conjunction  with  the  Security  Context  security
  924. service  it  enables  the  implementation  of  security  policies  defining  which  parts  of
  925. the MHS may handle messages with specified associated Security Labels.
  926. This  security  service  is  provided  by  the  Message  Security  Label  security   element.
  927. The integrity and  confidentiality  of  the  label  are  provided  by  the  Message  Argument
  928. Integrity and the Message Argument Confidentiality security elements.
  929. 10.2.7   Security Management Services
  930. A number of security  management  services  are  needed  by  the  MHS.  The  only  management
  931. services   provided   within   Recommendation   X.411    are    concerned    with    changing
  932. credentials and registering MTS-user security labels.
  933. 10.2.7.1      Change Credentials Security Service
  934. This  security  service  enables  one  entity  in  the  MHS   to   change   the   credentials
  935. concerning it held by another entity in  the  MHS.  It  may  be  provided  using  the  Change
  936. Credentials security element.
  937. 10.2.7.2      Register Security Service
  938. This  security  service  enables  the  establishment  at  an  MTA  of  the  Security   Labels
  939. which  are  permissible  for  one  particular  MTS-user.  It  may  be  provided   using   the
  940. Register security element.
  941.  
  942. 10.2.7.3      MS-Register Security Service
  943. The  security  service  enables  the  establishment  of   the   security   label   which   ar
  944. permissible for the MS-user.
  945.  
  946. 10.3     Security Elements
  947. The  following  clauses  describe  the  security  elements   available   in   the   protocols
  948. described  within  Recommendation  X.411  to  support  the  security  services  in  the  MHS.
  949. These security elements relate  directly  to  arguments  in  various  services  described  in
  950. Recommendation X.411. The objective of this  clause  is  to  separate  out  each  element  of
  951. the Recommendation  X.411  service  definitions  that  relate  to  security,  and  to  define
  952. the function of each of these identified security elements.
  953.  
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960.  
  961.  
  962.  
  963.  
  964. 10.3.1   Authentication Security Elements
  965. These  security   elements   are   defined   in   order   to   support   authentication   and
  966. integrity security services.
  967. 10.3.1.1      Authentication Exchange Security Element
  968. The  Authentication  Exchange  security  element  is  designed  to   authenticate,   possibly
  969. mutually, the identity of an MTS-user to an MTA,  an  MTA,  an  MS  to  a  UA,  or  a  UA  to
  970. an MS to  an  MTS-user.  It  is  based  on  the  exchange  or  use  of  secret  data,  either
  971. passwords,  asymmetrically  encrypted  tokens,  or  symmetrically  encrypted   tokens.    The
  972. result  of  the  exchange  is  corroboration  of  the  identity  of  the  other  party,  and,
  973. optionally, the transfer of confidential data which may be used in providing  the  Connection
  974. Confidentiality  and/or   the   Connection   Integrity   security   service   in   underlying
  975. layers. Such an authenication is only  valid  for  the  instant  that  it  is  made  and  the
  976. continuing validity of  the  authenticated  identity  depends  on  whether  the  exchange  of
  977. confidential data, or some other mechanism, is  used  to  establish  a  secure  communication
  978. path.  The  establishment  and  use  of  a  secure  communication  path.  The   establishment
  979. and use of a secure communication path is outside the scope of this Recommendation.
  980.  
  981. This  security  element  uses  the  Initiator  Credentials   argument   and   the   Responder
  982. Credentials  result  of  the  MTS-bind,  MS-bind  and  MTA-bind  services.  The   transferred
  983. credentials are either passwords or tokens.
  984. 10.3.1.2      Data Origin Authentication Security Elements
  985. These   security   elements   are   specifically   designed   to    support    data    origin
  986. authentication services, although they may also be used to  support  certain  data  integrity
  987. services.
  988. 10.3.1.2.1    Message Origin Authentication Security Element
  989. The  Message  Origin  Authentication  security  element  enables  anyone  who   receives   or
  990. transfers  message  to  authenticate  the  identity  of  the  MTS-user  that  originated  the
  991. message. This may mean the provision of the Message Origin Authentication or the Non-repudiation of Origin security service.
  992. The  security  element  involves  transmitting,  as  part   of   the   message,   a   Message
  993. Origin Authentication Check, computed as a function  of  the  message  content,  the  message
  994. Content  Identifier,  and  the  Message  Security  Label.  If  the  Content   Confidentiality
  995. security service is also required,  the  Message  Origin  Authentication  Check  is  computed
  996. as  a  function  of  the  enciphered  rather  than  the  unenciphered  message  content.   By
  997. operating on the message content  as  conveyed  in  the  overall  message  (i.e.,  after  the
  998. optional  Content  Confidentiality  security  element),  any  MHS  entity   can   check   the
  999. overall message integrity without the need to see the  plaintext  message  content.  However,
  1000. if  the  Content   Confidentiality   security   service   is   used,   the   Message   Origin
  1001. Authentication security element cannot be used  to  provide  the  Non-repudiation  of  Origin
  1002. security service.
  1003. The security  element  uses  the  Message  Origin  Authentication  Check,  which  is  one  of
  1004. the  arguments  of  the  Message  Submission,  Message   Transfer,   and   Message   Delivery
  1005. services.
  1006. 10.3.1.2.2    Probe Origin Authentication Security Element
  1007. Similar  to  the  Message  Origin  Authentication  security   element,   the   Probe   Origin
  1008. Authentication security element enables any MTA to authenticate the identity of the MTS-user which originated a probe.
  1009. This  security  element  uses  the  Probe  Origin  Authentication  Check,  which  is  one  of
  1010. the arguments of the Probe Submission service.
  1011. 10.3.1.2.3    Report Origin Authentication Security Element
  1012. Similar  to  the  Message  Origin  Authentication  security  element,   the   Report   Origin
  1013. Authentication security element enables  any  MTA  or  MTS-user  who  receives  a  report  to
  1014. authenticate the identity of the MTA which originated the report.
  1015. This security  element  uses  the  Report  Origin  Authentication  Check,  which  is  one  of
  1016. the arguments of the Report Delivery service.
  1017. 10.3.1.3      Proof of Submission Security Element
  1018. This  security  element  provides  the  originator  of  a   message   with   the   means   to
  1019. establish that a message was accepted by the MHS for transmission.
  1020. The  security  element  is  made  up   of   two   arguments:   a   request   for   Proof   of
  1021. Submission, sent with a message at submission time, and the Proof of Submission, returned  to
  1022. the MTS-user as  part  of  the  Message  Submission  results.  The  Proof  of  Submission  is
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029. generated by  the  MTS,  and  is  computed  as  a  function  of  all  the  arguments  of  the
  1030. submitted message, the Message Submission Identifier, and the Message Submission Time.
  1031. The  Proof  of  Submission  argument  can  be  used  to  support  the  Proof  of   Submission
  1032. security service. Depending on the  security  policy  in  force,  it  may  also  be  able  to
  1033. support the (stronger) Non-repudiation of Submission security service.
  1034. The  Proof  of  Submission  Request  is  an  argument  of  the  Message  Submission  service.
  1035. The Proof of Submission is one of the results of the Message Submission service.
  1036. 10.3.1.4      Proof of Delivery Security Element
  1037. This  security  element  provides  the  originator  of  a   message   with   the   means   to
  1038. establish that a message was delivered to the destination by the MHS.
  1039. The  security  element  is  made  up  of  a  number  of  arguments.  The  message  originator
  1040. includes a Proof of Delivery  Request  with  the  submitted  message,  and  this  request  is
  1041. delivered to each recipient with  the  message.  A  recipient  may  then  compute  the  Proof
  1042. of Delivery as a function  of  a  number  of  arguments  associated  with  the  message.  The
  1043. proof of delivery  is  returned  by  the  MTS  to  the  message  originator,  as  part  of  a
  1044. report on the results of the original Message Submission.
  1045. The  Proof  of  Delivery  can  be  used  to  support   the   Proof   of   Delivery   security
  1046. service. Depending on the security policy in force, it  may  also  be  able  to  support  the
  1047. (stronger) Non-repudiation of Delivery security service.
  1048. The  Proof  of  Delivery  Request  is  an  argument  of  the  Message   Submission,   Message
  1049. Transfer, and  Message  Delivery  services.  The  Proof  of  Delivery  is  both  one  of  the
  1050. results of the Message Delivery service and one of  the  arguments  of  the  Report  Transfer
  1051. and Report Delivery services.
  1052.  
  1053. Note - Non-receipt of a Proof of Delivery does not imply non-delivery.
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067. 10.3.2   Secure Access Management Security Elements
  1068. These  security  elements   are   defined   in   order   to   support   the   Secure   Access
  1069. Management security service and the security management services.
  1070. 10.3.2.1      Security Context Security Element
  1071. When  an  MTS-user  or  an  MTA  binds  to  an  MTA   or   MTS-user,   the   bind   operation
  1072. specifies the security context of the  connection.  This  limits  the  scope  of  passage  of
  1073. messages by reference  to  the  labels  associated  with  messages.  Secondly,  the  Security
  1074. Context of the connection may be temporarily altered for submitted or delivered messages.
  1075. The  Security  Context  itself  consists  of  one  or  more  Security  Labels  defining   the
  1076. sensitivity of interactions that may occur in line with the security policy in force.
  1077. Security Context is an argument of the MTS-bind and MTA-bind services.
  1078. 10.3.2.2      Register Security Element
  1079. The  Register  security  element  allows  the  establishment  at  an  MTA  of  an  MTS-user's
  1080. permissible security labels.
  1081. This  security  element  is  provided  by  the  Register  service.   The   Register   service
  1082. enables an  MTS-user  to  change  arguments,  held  by  the  MTS,  relating  to  delivery  of
  1083. messages to that MTS-user.
  1084.  
  1085. 10.3.2.3      MS-Register Security Element
  1086.  
  1087. The   MS-Register   security   element   allows   the   establishment   of   the    MS-user's
  1088. permissible security labels.
  1089.  
  1090. This  security  element  is  provided   by   the   MS-Register   service.   The   MS-Register
  1091. services enables an MS-user to change arguments held by the  MS  relating  to  the  retrieval
  1092. of messages to that MS-user.
  1093.  
  1094. 10.3.3   Data Confidentiality Security Elements
  1095. These  security  elements,  based  on  the  use  of  encipherment,  are  all  concerned  with
  1096. the provision of confidentiality of data passed from one MHS entity to another.
  1097. 10.3.3.1      Content Confidentiality Security Element
  1098. The  Content  Confidentiality  security  element  provides  assurance  that  the  content  of
  1099. the  message  is  protected  from  eavesdropping   during   transmission   by   use   of   an
  1100. encipherment security element. The security element operates such  that  only  the  recipient
  1101. and sender of the message know the plaintext message content.
  1102. The  specification  of  the  encipherment  algorithm,   the   key   used,   and   any   other
  1103. initialising data are conveyed using the Message Argument  Confidentiality  and  the  Message
  1104. Argument  Integrity  security  elements.  The  algorithm   and   key   are   then   used   to
  1105. encipher or decipher the message contents.
  1106. The   Content   Confidentiality   security   element   uses   the   Content   Confidentiality
  1107. Algorithm Identifier, which is an argument  of  the  Message  Submission,  Message  Transfer,
  1108. and Message Delivery services.
  1109. 10.3.3.2      Message Argument Confidentiality Security Element
  1110. The   Message    Argument    Confidentiality    security    element    provides    for    the
  1111. confidentiality, integrity, and, if required, the irrevocability of recipient data associated
  1112. with  a  message.  Specifically,  this  data  will  comprise  any  cryptographic   keys   and
  1113. related data that is necessary for the confidentiality and  integrity  security  elements  to
  1114. function properly, if these optional security elements are invoked.
  1115. The  security  element  operates  by  means  of  the  Message   Token.   The   data   to   be
  1116. protected  by  the  Message  Argument  Confidentiality  security  element   constitutes   the
  1117. Encrypted Data within the Message Token. The Encrypted  Data  within  the  Message  Token  is
  1118. unintelligible to all MTAs.
  1119. The  Message  Token  is  an  argument  of  the  Message  Submission,  Message  Transfer,  and
  1120. Message Delivery services.
  1121. 10.3.4   Data Integrity Security Elements
  1122. These  security  elements  are  provided  to  support  the  provision  of   data   integrity,
  1123. data authentication, and non-repudiation services.
  1124. 10.3.4.1      Content Integrity Security Element
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.  
  1131. The  Content  Integrity  security  element  provides  protection  for  the   content   of   a
  1132. message against modification during transmission.
  1133. This security  element  operates  by  use  of  one  or  more  cryptographic  algorithms.  The
  1134. specification of  the  algorithm(s),  the  key(s)  used,  and  any  other  initialising  data
  1135. are  conveyed  using  the  Message  Argument  Confidentiality  and   the   Message   Argument
  1136. Integrity security elements. The result of the application  of  the  algorithms  and  key  is
  1137. the  Content  Integrity  Check,  which  is  sent  in  the  message  envelope.  The   security
  1138. element is only available  to  the  recipient(s)  of  the  message  as  it  operates  on  the
  1139. plaintext message contents.
  1140. If  the  Content  Integrity  Check  is  protected  using  the  Message   Argument   Integrity
  1141. security element then, depending on the  prevailing  security  policy,  it  may  be  used  to
  1142. help provide the Non-repudiation of Origin security service.
  1143. The  Content  Integrity  Check  is  an  argument   of   the   Message   Submission,   Message
  1144. Transfer, and Message Delivery services.
  1145. 10.3.4.2      Message Argument Integrity Security Element
  1146. The Message  Argument  Integrity  security  element  provides  for  the  integrity,  and,  if
  1147. required,  the   irrevocability   of   certain   arguments   associated   with   a   message.
  1148. Specifically, these arguments may comprise  any  selection  of  the  Content  Confidentiality
  1149. Algorithm  Identifier,  the  Content  Integrity  Check,  the  Message  Security  Label,   the
  1150. Proof of Delivery Request, and the Message Sequence Number.
  1151. The  security  element  operates  by  means  of  the  Message   Token.   The   data   to   be
  1152. protected by the Message Argument Integrity  security  element  constitutes  the  signed-data
  1153. within the Message Token.
  1154. The  Message  Token  is  an  argument  of  the  Message  Submission,  Message  Transfer,  and
  1155. Message Delivery services.
  1156. 10.3.4.3      Message Sequence Integrity Security Element
  1157. The  Message  Sequence  Integrity  security  element  provides  protection  for  the   sender
  1158. and  recipient  of  a  message  against  receipt  of  messages  in  the   wrong   order,   or
  1159. duplicated messages.
  1160. A  Message  Sequence  Number  is  associated  with  an  individual   message.   This   number
  1161. identifies  the  position  of  a  message  in  a  sequence  from  one   originator   to   one
  1162. recipient. Therefore each originator-recipient pair requiring to use  this  security  element
  1163. will have to  maintain  a  distinct  sequence  of  message  numbers.  This  security  element
  1164. does not provide for initialisation or synchronisation of Message Sequence Numbers.
  1165. 10.3.5   Non-repudiation Security Elements
  1166. There  are  no  specific  Non-repudiation  security  elements   defined   in   Recommendation
  1167. X.411.  The  non-repudiation  services  may  be  provided  using  a  combination   of   other
  1168. security elements.
  1169. 10.3.6   Security Label Security Elements
  1170. These security elements exist to support security labelling in the MHS.
  1171. 10.3.6.1      Message Security Label Security Element
  1172. Messages may  be  labelled  with  data  as  specified  in  the  prevailing  security  policy.
  1173. The Message Security Label is  available  for  use  by  intermediate  MTAs  as  part  of  the
  1174. overall security policy of the system.
  1175. A Message Security Label may be  sent  as  a  message  argument,  and  may  be  protected  by
  1176. the  Message   Argument   Integrity   or   the   Message   Origin   Authentication   security
  1177. element, in the same manner as other message arguments.
  1178. Alternatively,  if  both  confidentiality   and   integrity   are   required,   the   Message
  1179. Security  Label  may  be  protected  using  the  Message  Argument  Confidentiality  security
  1180. element. In this case the Message Security Label  so  protected  is  an  originator-recipient
  1181. argument, and may differ from the Message Security Label in the message envelope.
  1182. 10.3.7   Security Management Security Elements
  1183. 10.3.7.1      Change Credentials Security Element
  1184. The Change Credentials  security  element  allows  the  credentials  of  an  MTS-user  or  an
  1185. MTA to be updated.
  1186. The security element is provided by the MTS Change Credentials service.
  1187. 10.3.8   Double Enveloping Technique
  1188. Additional protection  may  be  provided  to  a  complete  message,  including  the  envelope
  1189. parameters,  by  the  ability  to  specify  that  the  content  of  a  message  is  itself  a
  1190.  
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196.  
  1197.  
  1198.  
  1199.  
  1200.  
  1201. complete message, i.e., a Double Enveloping Technique is available.
  1202. This technique is available  though  the  use  of  the  Content  Type  argument  which  makes
  1203. it possible  to  specify  that  the  content  of  a  message  is  an  Inner  Envelope.   This
  1204. Content Type means  that  the  content  is  itself  a  message  (envelope  and  content)  for
  1205. forwarding by the recipient named on the  outer  envelope  to  the  recipient  named  on  the
  1206. Inner Envelope.
  1207. The  Content  Type  is  an  argument  of  the  Message  Submission,  Message  Transfer,   and
  1208. Message Delivery services.
  1209.  
  1210.